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Executive Summary 



Mobile code is computer code that is produced on one node of a computer network but is 
transferred and executed on another network node. A mobile agent is a mobile software module 
composed of autonomous mobile code. Mobile agent software is a promising new computing 
paradigm for distributed computing in a large computer network environment, because of the 
autonomy and efficiency of mobile code. 

However, mobile code is vulnerable to security problems, including malicious agents, 
and malicious hosts. A malicious agent is an agent that performs harmful actions on an agent 
host Possible damaging actions include unauthorized access, modification and overuse of local 
resources, such as sensitive data, system calls, and CPU time. A malicious host is a host 
computer that performs harmful actions on a mobile agent. Because an agent is executed in an 
environment that an agent host provides, there are a number of ways that an agent host can attack 
an agent, including spying out and manipulating agent code, data, and control flow; listening to 
and tampering with data exchange between an agent and agent owner; executing code 
incorrectly; and denying execution and masquerading as another host. In addition, reverse 
engineering (the process of decompilation of a mobile agent bytecode to obtain its source code) 
is also a great threat for Java-based mobile agents. That is, if a malicious host can obtain the 
source code of an agent, the agent can be manipulated with possibly harmful results. 

All of the information attacks listed above, for example, become much easier based on 
the analysis of the source code of a mobile agent. To defend against terrorist attacks in 
cyberspace, it is clear that mobile code — as part of the nation's information infrastructure — 
must be well-protected. 

In the course of the Mobile Code Security (MCS) project supported by the US Air Force 
Research Laboratory, a MCS Framework has been developed by Fraunhofer CRCG. The MCS 
Framework provides a multi-layered approach to safeguarding mobile agents, and includes 
technologies to support 



• complete obfuscation, 

• encrypted execution, and 

• code watermarking technologies. 

Complete Obfuscation 

Code obfuscation is a technology to hide or remove symbolic information in mobile code so 
that source code can be protected even if a program is decompiled. Using the MCS Framework 
developed by Fraunhofer CRCG, mobile code is protected up to the Java system class level. This 
technology provides mobile code complete obfuscation from application classes to system classes, so 
it is a much stronger protection than traditional obfuscation approaches which only obfuscate 
application classes. Mobile code protected with me MCS Framework is very difficult to reverse- 
engineer and manipulate, and this technique can also be used for protection of intellectual property 
rights and classified data. 
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Encrypted Execution 

An encrypted execution framework based oh a customized Java class loader has also 
been developed as part of the MCS Framework. With the customized mobile code class loader, 
Java system classes remain obfuscated and encrypted at run time, therefore static or dynamic 
analysis of the mobile code is extremely unlikely, which greatly enhances mobile code security. 

Code Watermarking 

Code watermarking is a technology to embed a secure and invisible label in mobile code. 
Watermarks embedded in mobile code can authenticate not only mobile code, but watermarks 
embedded in system classes can be used to authenticate the execution environment on a remote 
host. The robustness of a watermark measures the difficulty of removing the watermark from 
mobile code. A non-robust watermark is called a "fragile watermark," and it is this fragility that 
helps to authenticate mobile code. More robust watermarks can survive piracy attacks, and thus 
can be used for intellectual property protection. The fragile Java bytecode watermarking 
techniques developed at Fraunhofer CRCG currently support mobile code authentication. Robust 
watermarking techniques for copyright protection have been designed and are currently being 
implemented. The encrypted execution mechanism described above also supports secure 
execution of watermarked mobile code, which provides additional protection from attack for 
software watermarks. 

Remote execution of mobile code was formerly risky and dangerous in an insecure 
malicious host environment However, using the MCS Framework developed at Fraunhofer 
CRCG — consisting of complete obfuscation, encrypted execution and code watermarking — 
mobile code can be safely executed on remote hosts. With security risks minimized, large-scale 
mobile agent-based applications such as network management can now be developed. 
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MULTI-LAYER PROTECTION OF 
MOBILE CODE 

Chenghui Luo, Ph.D. 

Secure Distributed Technologies 
Fraunhofer Center for Research in Computer Graphics, Inc. 
321 South Main St. 
Providence, RI 02903 

1 Introduction and Overview 

Mobile code is computer code that is produced on one node of a computer network but is 
transferred and executed on another network node. A mobile agent is a mobile software module 
composed of autonomous mobile code. Mobile agent software is a promising new computing 
paradigm for distributed computing in a large computer network environment, because of the 
autonomous and efficient nature of mobile code. 

1.1 The Mobile Code Security Problem 

However the mobile code is vulnerable to security problems, including malicious agents, 
and malicious hosts. A malicious agent is an agent that performs harmful actions on an agent 
host. Possible damaging actions include unauthorized access, modification and overuse of loca 
resources, such as sensitive data, system calls, and CPU time. A malicious host is a host 
computer that performs harmful actions on a mobile agent. Because an agent is executed in an 
environment that an agent host provides, there are a number of ways that an agent host can attack 
an agent, including spying out and manipulating agent code, data, and control flow; listening to 
and tampering with data exchange between an agent and agent owner, executing code 
incorrectly; and denying execution and masquerading as another host. 

In addition, reverse engineering (the process of decompilation of a mobile agent bytecode 
to obtain its source code) is also a great threat for Java-based mobile agents. That is, if a 
malicious host can obtain the source code of an agent, the agent can be manipulated with 
possible harmful results. 

All of the information attacks listed above become much easier based on the analysis of 
the source code of a mobile agent. To defend against terrorist attacks in cyberspace, it is clear 
that mobile code — as part of the nation's information infrastructure — must be well-protected. 

1.2 Solutions Developed by Fraunhofer CRCG 

Fraunhofer CRCG's solution to the mobile code security problems is its Mobile Code Security 
Framework, including complete obftiscation, encrypted execution and code watermarking 
technologies. These technologies were developed in 2001 with the support of the US Air Force 
Research Laboratory. 
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Code obfuscation is a technology to hide or remove symbolic information in mobile code so 
that source code can be protected even if a program is decompiled. Using the MCS Framework 
developed by Fraunhofer CRCG, mobile code is protected up to the Java system class level. This 
technology provides mobile code complete obfuscation from application classes to system classes, so 
it is a much stronger protection than traditional obfuscation approaches which only obfuscate 
application classes. Mobile code protected with the MCS Framework is very difficult to reverse- 
engineer and manipulate, and this technique can also be used for protection of intellectual property 
rights and classified data. 

Encrypted Execution 

An encrypted execution framework based on a customized Java class loader has also 
been developed as part of the MCS Framework. With the customized mobile code class loader, 
Java system classes remain obfuscated and encrypted at run time, therefore static or dynamic 
analysis of the mobile code is extremely unlikely, which greatly enhances mobile code security. 

Code Watermarking 

Code watermarking is a technology to embed a secure and invisible label in mobile code. 
Watermarks embedded in mobile code can authenticate not only mobile code, but watermarks 
embedded in system classes can be used to authenticate the execution environment on a remote 
host The robustness of a watermark measures the difficulty of removing the watermark from 
mobile code. A non-robust watermark is called a "fragile watermark," and it is this fragility that 
helps to authenticate mobile code. More robust watermarks can survive piracy attacks, and thus 
can be used for intellectual property protection. The fragile Java bytecode watermarking 
techniques developed at Fraunhofer CRCG currently support mobile code authentication Robust 
watermarking techniques for copyright protection have been designed and are currently being 
implemented. The encrypted execution mechanism described above also supports secure 
execution of watermarked mobile code, which provides additional protection from attack for 
software watermarks. 

Remote execution of mobile code was formerly risky and dangerous in an insecure 
malicious host environment However, using the MCS Framework developed at Fraunhofer 
CRCG — consisting of complete obfuscation, encrypted execution and code watermarking — 
mobile code can be safely executed on remote hosts. With security risks minimized, large scale 
mobile agent-based applications such as network management can now be developed. 

2 Research Background 

Mobile code is now ubiquitous on the Internet Many web pages become "active" by 
including mobile code such as Java™ applets and JavaScript or ActiveX scripts. Mobile code is also 
used to implement features in devices such as cellular phones. When a user accesses one of these 
features on a cellular phone, mobile code for the feature is downloaded to the cellular phone and then 
used in the interactions that involve the feature. 
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When mobile code becomes an autonomous program and travels from host to host on a 
network, it evolves into mobile agents. Compared to mobile code, mobile agents typically move from 
host to host to accomplish specified missions autonomously and collaboratively. Mobile agents 
emerge as promising distributed computing paradigm to replace the conventional client-server model. 
With mobile agent platforms such as IBM Aglets [Karjoth et al, 1998] and Mitsubishi Concordia 
[Walsh et al, 1998], more and more mobile agent applications such as travel agents, auction agents 
and e-commerce agents, can be conveniently developed. Partially supported by DARPA and ARL 
during 1997-1999, Fraunhofer CRCG also developed a Digital Watermark Agent application with 
CRCG's own lightweight mobile agent platform [Zhao and Luo, 1999]. 

2.1 Mobile Code Security Problems 

Because mobile code originates from a remote, possibly "untrusted" system, mobile code 
could be a potential security threat to a mobile agent host, e.g., unauthorized access, modification 
and overuse of local resources, such as sensitive data, system calls, and CPU time, just like 
viruses. This problem is called "malicious agent" problem and although this problem seems the 
major and natural security problem for a mobile agent host, it can be basically solved by 
confining a mobile agent in a sandbox with fine-grained access control policies. A surprisingly 
much more difficult problem is the "malicious host", which can exploit a mobile agent almost 
freely, because a mobile agent is executes in an environment that is provided and controlled by 
the malicious host, and thus can be easily accessed by a mobile agent host. Because an agent is 
executed in an environment that an agent host provides, there are a number of ways that an agent 
host can attack an agent [Hohl, 1998], including 

• spying out and manipulating agent code, data, and control flow; 

• listening to and tampering with data exchange between an agent and agent owner; 

• executing code incorrectly; and 

• denying execution and masquerading as another host. 

Besides these malicious host attacks, agent reverse engineering, the process of 
decompilation of a mobile agent bytecode to obtain its source code, is also a great threat for 
mobile agents [Luo and Zhao, 1999]. Today, it is not a secret that Java programs (applets or 
applications) can be easily decompiled and reverse engineered from Java bytecode to Java source 
code. Although all computer programs are theoretically subject to decompilation, Java's rich 
symbolic information in class files and Java's dynamic link mechanism makes the chance of 
successfully decompiling Java programs great, using some commercial decompilers. The 
consequence of decompilation is serious, e.g., it will become cheap and easy to steal intellectual 
property or classified data embedded in mobile code, to alter legitimate programs and 
redistribute them, and for the case of a mobile agent, a malicious host can easily manipulate a 
mobile agent. All of the information attacks listed above, for example, become much easier 
based on the analysis of a mobile agent's source code. Because of these reasons, research efforts 
of Fraunhofer CRCG have focused on the protection of mobile code against malicious hosts. 

2.2 Related Work 

The malicious host problem is recognized by many researchers as a much harder task; 
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currently there are many diverse opinions about this problem and various solutions have been 
proposed to solve it. 

2.2.1 Secure Hardware 

Some researchers argued that it is doubtful that an agent could keep a secret (e.g., a secrert 
key for decryption) [Gong 19971, since the information belonging to a mobile agent is 
completely available to its host system. Some even claimed that it is impossible to prevent agent 
tampering unless trusted hardware is available in agent platforms [Karjoth et al. 1998], Such 
belief gives an impression that the hardware approach is the only one that can lead to highly 
secure agent systems. Currently there are some commercial products in this category, such as 
smart cards, including Sun Microsystems' Java Card [Sun Microsystems 1997]. However, a 
closer look into Java Card finds that currently Java Card is not sufficient for large-scale 
computation. For example, the current specification of the Java Card only supports a small subset 
of the Java language, and it is not able to load classes dynamically, though it is enough for 
typical smart card applications, such as payment and some intelligent features. A hardware 
approach could be successful, provided that serious hardware can be developed and somehow 
integrated into current computer hardware. Otherwise, it is not a practical approach. 

2.2.2 Mobile Cryptography 

Although protecting mobile agents against tampering attempts by the executing host is 
much harder, not everyone believes that computation privacy for mobile code is impossible 
without tamper resistant hardware, or that an agent cannot keep a secret, such as a secret key. In 
[Sander and Tschudin 1998], for the first time, it was pointed out that indeed there was an error 
in this reasoning. They explained that although that opinion was true for agents in clear text 
form, it was not for agents in cryptographic form in which both the data and the functions of an 
agent were encrypted. In such a case, through computing with encrypted data and function, a 
software-only approach for providing computation privacy for mobile code is possible. Sander 
and Tschudin demonstrated this approach with a mobile code fragment that computes an 
algebraic circuit (a polynomial). They also described another method in which a mobile agent 
could digitally sign its output securely. This second approach is on the right track, and with 
modification and customization, the basic idea of computing with encrypted data and function 
could work successfully for more and more mobile agent applications. But in practice, this 
approach is still incomplete, because the transformation that Sander and Tschudin used can only 
be applied to algebraic circuits, a universal transformation is hard to construct. 

2.2.3 Time Limited Blackbox 

In [Hohl 1998], another approach was presented that partially solved the malicious host 
problem. The idea here is to create a blackbox out of an original agent. A blackbox is an agent 
that performs the same work as the original agent, but is of a different structure. This difference 
allows the agent dispatcher to assume a certain agent protection time interval, during which it is 
impossible for an attacker to discover relevant data or manipulate the execution of the agent. 
After that time interval the agent and some associated data become invalid, and the agent cannot 
migrate or interact anymore, which prevents the exploitation of attacks after the protection 
interval. This idea seems vague because it is hard to implement with different CPU clocks and 
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execution environments, and there are no mechanisms to block a host's access to an agent's 
secret data. 

2.2.4 Detection Objects 

Because complete prevention of a host's attacks on an agent is hard to achieve, some 
researchers have turned to methods that detect evidence of a host's attacks. In [Meadows 1997], 
a rough idea about "detection objects" was proposed. Detection objects are objects sent to hosts 
solely for detection purposes, therefore they may contain some data or function to fool a host 
system so that if an host tries to tamper with them, the objects dispatcher has a way to detect the 
host's misbehavior. This way, an agent dispatcher can verify if a host is a malicious one. 

2.2.5 Protective Assertions 

A similar approach, called "protective assertions", was presented in [Kassab & Voas 
1998]. Their goal was to make it much harder for an agent to be tampered with. By inserting 
some assertions into the agent source code, an agent can check the conditions specified in the 
assertions at runtime. Agent assertions are usually Boolean functions that evaluate to be true 
when an agent execution state satisfies a semantic condition, and false otherwise. Kassab et al. 
also proposed to let the agent assertions output more than Boolean values in order to increase the 
agent observability. Based on the output results of assertion checking which are sent to the agent 
dispatcher, an agent dispatcher (owner) has a way to detect if its agent has been attacked. 

22.6 Cryptographic Traces 

In [Vigna 1998], a detection mechanism was presented based on execution cryptographic 
traces. It allows one to detect attacks against code, state, and the execution flow of mobile 
software components. Cryptographic traces are logs of the operations performed by an agent 
during its lifetime. Using these traces, an agent dispatcher can check — following agent 
termination — to see if the execution history of the agent conforms to a correct execution. For 
example, an agent dispatcher may verify part of the agent's logs, to discover if there are any 
signs of a host's attacks, by repeating the agent's execution on the same secure environment. 
This method gives a somewhat reasonable way for the detection of malicious hosts, but how to 
generate this cryptographic trace is not further discussed. 

Based on this research review, although there was much research work towards the 
malicious host problem, the problem is far from being solved. Based on the current research, and 
previous work at Fraunhofer CRCG on mobile agent security, it was found that a multi-layer 
approach is practical - in this case, a mobile agent could be armed with 3 layers of information 
armors as described below. 

3 Fraunhofer CRCG Mobile Code Security Framework 
3.1 The Fraunhofer CRCG 3-layer Solution 

The malicious host is a very difficult problem, and some researchers have even claimed 
that it is impossible to verify if an agent is correctly executed on a malicious host [Kaijoth et al., 
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1998] After reviewing the literature, it was determined that a multi-layer approach could provide 
mobile agents much better protection. Please refer to Figure 1. The mobile agent protectxon 
mechanism developed at Fraunhofer CRCG consists of 3 layers of information armor: 

1. The first layer is agent code obfuscation. This layer significantly hides 
symbolic information such as class, field and method names; prevents 
understanding of an agent's source code based on static analysis; and helps to 
protect an agent's internal procedures and secrets. 

2. The second layer is for secure execution of completely obfuscated agent code. 
This layer provides a customized class loader to dynamically load obfuscated 
mobile code and execute the code in an encrypted fashion. Both the first 
(obfuscation) and the third (dynamic watermarking) layers are supported 
through this layer. 

3. The third layer is to watermark an agent's code, which is used to detect 
attacks from a malicious host. This third layer allows a mobile agent to detect 
intrusion and dispatch information back to its agency (original agent 
dispatcher), so that the agency is notified that its agent has been attacked. 

The integration of all of these complementary layers greatly limits the possibility of 
successful malicious attacks. In previous research, some techniques such as secret spreading, 
assertions [Kassab & Voas 1998] and time constraints [Hohl 19981, were quite different from 
each other, and it has been difficult to integrate them together into a single, mobile agent 
application. Based on CRCG's customized class loader-based encrypted execution framework, 
these three layers of information armor have been successfully integrated into Fraunhofer CRCG 
mobile code security framework and it supports secret spreading and assertions m a consistent 
way. This greatly simplifies the complexity of mobile code security management. 




Figure 1. CRCG 3-layer information armor for agent protection. 
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3.2 Complete Obfuscation 

There exist a few obfuscation techniques [Collberg, 1997]. For example, data obfuscation 
changes the storage modes, encoding methods, aggregation, and/or ordering of data structures. Control 
obfuscation may hide the real control flow behind irrelevant or never executed statements, or change 
the reducible code to non-reducible. All of these obfuscators generally take the common approach of 
renaming meaningful symbolic names to meaningless names. This technique effectively renders the 
decompiled source code difficult for a human being to understand, even if one has plain text source 
code Some of these obfuscators also obfuscate the control flow of a Java program, e.g., by inserting 
many GoTo instructions to confuse decompilers. In practice, this approach works well, and not many 
decompilers can correctly analyze the obfuscated control flow and output the corresponding source 
code. 

As seen above, one common way of obfuscating a program is to replace all of the names 
in the program with names that are legal in the programming language but are as meaningless as 
possible to a human being reading the program. One of the key observations in the Fraunhofer 
CRCG research effort has been that this kind of technique is generally only applied to an 
bytecode of an application package, but not to the Java library system classes. Without a 
developer's meaningful symbolic names, an obfuscated package is harder to understand, but all 
the meaningful symbolic names of Java library classes in source code still gives a clear clue 
about the internal logic of a Java package. 

Directly extending traditional obfuscation techniques to Java library classes will simply 
make an application package not executable, because a Java virtual machine may not be able to 
link those application and library classes. Although Java's design essentially make it vulnerable 
to decompilation, it is also Java's dynamic class loading feature that make it possible to fix the 
hole Simply speaking, the complete obfuscation technique developed at Fraunhofer CRCG 
obfuscates all symbolic information in a Java software package including static data, and uses a 
customized Java class loader to load, link and execute the completely obfuscated package. 

The Fraunhofer CRCG obfuscation framework contains the following three major 
components: 

• symbolic name obfuscating, 

• library-related symbolic name encrypting, and 

• runtime library-related symbolic name recovering. 
The encrypting and recovering steps are associated with a key. 

At the symbolic name obfuscation step, all symbolic information are transformed to 
meaningless names, for both the application and library level classes. Next, for security reasons, to 
prevent attackers from finding the original library classes, all library-related symbolic information in 
an application is encrypted using a key. Finally, at runtime, the symbolic information of library classes 
will be recovered by encrypting Java library classes with the same encryption key so that the two 



11 



encrypted symbolic names can link and execute. This global picture is illustrated in the following 
figure. 
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Figure 2. The Complete Obfuscation Framework 

The above three components correspond to three different time periods of the software: the 
obfuscating and encrypting processes happen after the development and before the release of the 
software; and after a software is released, the recovering process happens at the software execution 
phase At the development and the execution phases, the software package is well-linked with a 
library, but during the release and before the execution phase, the library data names remain encrypted 
and the package is not well linked with the library. 

Library data linking is a very critical component in this obfuscation architecture. For security 
reasons, this part must be made hard enough for a pirate to attack at runtime. To achieve this goal, in 
the Fraunhofer CRCG framework, the plain library data names are first encrypted with a key, and then 
the encrypted names are mapped to the obfuscated library data names. Thus, in the release version of a 
software package, the library data names are both encrypted and obfuscated. 

To link and execute the package, one must have a key to encrypt library-related symbolic 
names Note that here one does not use a key to decrypt those names because doing so wril reveal the 
original library names. Instead, one encrypts the library classes with the original encryption key. See 
Figure 3. This way, the library classes can still be linked together. 
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Figure 3. Encryption to link 



12 



n » wra y v p q .0^0 ^? o K 




33 Encrypted Execution 

Encrypted execution (also called "computing with encrypted data" or "computing with 
encrypted function") might be the last resort for strong mobile code protection. This approach is 
a pure software approach, and its key point is to execute an agent on a host while the agent keeps 
its data (or function) encrypted [Sander and Tschudin, 1998]. But for computing with encrypted 
data, a large set of natural privacy homomorphism approaches are shown to be insecure [Brickell 
and Odlyzko, 1992], and a secure privacy homomorphism is hard to construct (for example, 
some approaches only work for polynomials [Sander and Tschudin, 1998]), which renders this 
encrypted data approach impractical for mobile code protection. 

The major drawback of computing with encrypted function is complexity in terms of 
computation, communication and rounds, and this is the cost of having very strong security 
properties related to cryptographic or information-theoretic assumptions. The complexity and 
interactive rounds of the encrypted function approach is also not practical for mobile code, since 
it makes it very difficult to autonomously deploy and execute tasks remotely. 

Based on the above review, it was found by Fraunhofer CRCG that although the 
encrypted computing approach was on the right track, many open research questions remained, 
such as how to encrypt data and functions to achieve the non-interactivity of mobile computing. 
For practical strong security, a class loader-based encrypted execution framework was developed 
by Fraunhofer CRCG. 

The idea of the Fraunhofer CRCG class loader-based encrypted execution framework is 
to execute a mobile code package with encrypted Java system classes, through the means of the 
Fraunhofer CRCG customized class loaders. Please refer to Figure 4. This way, although the 
whole mobile code package is not completely encrypted during execution, if the system classes 
are encrypted, static or dynamic analysis of the mobile code is much harder, because all the 
system-related parts are encrypted in the mobile code application. 
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Figure 4. Customized Class Loader-based Encrypted Execution Framework 

To make mobile code even harder to modify at both static and dynamic code level, a 
class evolution solution has been developed by Fraunhofer CRCG . Class evolution means that 
the definition of a class can be changed at runtime through a customized class loader. Even with 
a debugger, a class controlled in this way is hard to modify, because certain bytecode or internal 
states of a mobile code application may remain encrypted, and an attacker will not be sure which 
code or data to modify at a certain time during the execution. Class evolution is also used for the 
dynamic watermarking techniques developed by Fraunhofer CRCG (section 3.4). 

Compared with the general purpose encrypted computing approach, the class loader- 
based encrypted execution framework developed by Fraunhofer CRCG may be considered a 
software engineering-oriented approach because the encryption and execution occurs withm 
customized Java class loaders, instead of keeping all the data and functions encrypted during 
execution as in the case of encrypted computing. 

Recall that decompilation is one of the major practical means of malicious host attacks. 
This class loader-based encrypted execution framework significantly deters this attack, because 
with partial encryption, all the classes are correctly generated and linked based on the encrypted 
system classes only at runtime, thus source code is hard to obtain through decompilation of static 
bytecode of a mobile code application. This shift of static information to runtime generation is 
very useful for preventing decompilations. 

This customized class loader-based encrypted execution framework is well adapted to the 
Fraunhofer CRCG 3-layer information armor for mobile code security. This framework is 
seamlessly integrated with 



• the obfuscation framework that protects the source code of mobile code, 
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• the watermarking component which supports detection of malicious host attacks, 

• dynamic loading and class evolution for assertions and time limited constraints. 

3.4 Code Watermarking 

Generally speaking, a watermark is an invisible, robust, and secure label embedded in a 
digital content for the purpose of ownership identification. Software watermarks are used for 
software copyright protection, just same as the media watermark case [Cox et al, 1996; Zhao and 
Koch, 1995]. In a mobile code scenario, however, watermarks embedded in mobile code can be 
used to detect attacks from mobile hosts. 

The idea of watermarking agent code is as follows. Before an agent is dispatched, it is 
first watermarked by the agency. When the watermarked agent arrives at a host, it signals its 
arrival and executes. Upon completion, the agent will check its watermark, and communicate 
back to the remote agency. If the watermark has been changed or cannot be found, then the agent 
will detect that, and notify the remote agency. If, however, the agency does not receive a signal 
at all from an agent within some expected time interval after arrival at a host, the agency knows 
that the agent has been significantly modified. So an agency can use this as a way to detect 
modification of agent code by a malicious host. 

There ate currently two approaches to watermark a Java program: to embed a watermark 
statically in the program's bytecode, or dynamically in the status of a program's execution. 
Generally, for all watermarking techniques — both media and software watermarking — 
robustness is a major problem. But for software watermarking, the invisibility requirement is an 
additional difficulty. Research by Fraunhofer CRCG has shown that many of these watermarking 
techniques require some amount of extra code in a certain format to be inserted into a program, 
such as [Monden et al, 2000], [Townsend and Collberg, 2000] and [Palsberg et al, 2000]. Some 
of them even require that the insertion occur at the source code level, which complicates 
software engineering and maintenance. 

The static watermark embedded in mobile code developed by Fraunhofer CRCG is a 
simple and easy scheme. Given a key, one first generates a set of locations in the bytecode 
(based on also some class information, such as the number of bytecodes in a method. This issue 
is discussed in section 4.3). Based on these locations, one inserts a bytecode "nop" — a no-op 
instruction which does nothing in a Java virtual machine, and thus doesn't change the 
functionality of the mobile code. When this same operation is performed at some later time to 
retrieve the watermark on a bytecode stream, the watermark is valid if and only if the result of 
this secret operation is identical to the watermark value. 

Compared with other static watermark techniques, the Fraunhofer CRCG implementation 
does not rely on a Java application's source code, but only bytecode. This approach relieves 
software developers from the burden of maintaining watermark-related source code. 

Fraunhofer CRCG uses class evolution to construct a dynamic watermark. First one 
inserts into the class a few extra, secret assertion methods with the known watermark as return 
value under certain conditions. Then these assertion methods are encrypted by encrypting blocks 



15 





of the bytecode of the methods with the given watermark key. Other class methods are encrypted 
by scrambling based on other keys or runtime values of certain fields. Next, each class is 
encrypted using class evolution (class evolution is a runtime class transforming mechanism that 
was used for encrypted execution. Here it is used for watermarking purposes). To do class 
evolution, one can develop a class loader for this class and make it dynamically load the 
bytecode streams of all of its methods from a byte array generated from all the methods, 
including the extra methods. 

To retrieve the watermark, execute the watermarked class using the customized class 
loader. Load the regular methods, then with the given watermark retrieval key, decrypt the 
bytecode of the extra methods and then load and execute them. The original watermark will be 
returned if there are no modifications. 

This dynamic watermarking technique can detect illegal runtime modifications, because 
if the assertions fail, the return value will be different from the original one, and the mobile code 
owner will know that this code has been executed incorrectly. Since the encrypted assertion 
method will be executed as usual, without giving extra clues that the agent is detecting 
modifications, this detection module may not be visible to a malicious host. 

4 Conclusions 

While mobile code-based computing is a promising new computing paradigm, security is 
a bottleneck, especially because it is very difficult to protect a mobile agent against malicious 
host attacks, such as decompilation. To better protect a mobile agent, various obfuscation 
techniques have been proposed and developed. In this research, Fraunhofer CRCG developed 
innovative complete obfuscation technologies, which push the frontier of obfuscation to Java 
library classes, and Fraunhofer CRCG further achieved stronger security by obfuscating and 
encrypting the Java library class-related symbolic names in a Java package. 

Research on general mobile code security has shown that secure execution may be the 
utmost solution of mobile code security problem. To achieve stronger mobile code security, 
Fraunhofer CRCG designed and developed a Java system library based encrypted execution 
framework. This framework makes use of Java's sophisticated class loading mechanism to load 
Java system classes and in execution of mobile code, it keeps these system classes hidden and 
encrypted. This approach naturally integrates with the Fraunhofer CRCG complete obfuscation 
framework, and it significantly improves the security of mobile code. Static analysis and 
dynamic modification of the mobile code are now much harder within this framework. 

While encrypted execution makes it almost impossible for a malicious host to modify and 
extract useful information at runtime, the Fraunhofer CRCG watermark approach makes it 
possible to detect any modifications that a malicious host tries to perform before or during the 
execution by embedding an invisible label. A static watermark is embedded into mobile code to 
detect modifications of code, and a dynamic watermark is embedded to detect runtime 
modifications of code and data. 

In summary, Fraunhofer CRCG has developed complete obfuscation and encrypted 
execution technologies for stronger mobile code security. Complete obfuscation and encrypted 
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execution are proactive protection of mobile code against malicious host attacks and the 
Fraunhofer CRCG Java bytecode watermarking framework provides a passive protection of 
mobile code by providing means of attack detection. The combination of watermarking, and 
obfuscation, as well as encrypted execution of Java bytecode, now provides a unified, 
complementary multi-layer protection - the Fraunhofer CRCG information armor for Java-based 
mobile code. 
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